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The Human Factors Implementation Team (HFIT) process has been used to verify human 
factors requirements for NASA International Space Station (ISS) payloads since 2003, 
resulting in $2.4 million in avoided costs. This cost benefit has been realized by greatly 
reducing the need to process time-consuming formal waivers (exceptions) for individual 
requirements violations. The HFIT team, which includes astronauts and their technical 
staff, acts as the single source for human factors requirements integration of payloads. 
HFIT has the authority to provide inputs during early design phases, thus eliminating 
many potential requirements violations in a cost-effective manner. In those instances 
where it is not economically or technically feasible to meet the precise metric of a given 
requirement, HFIT can work with the payload engineers to develop common sense 
solutions and formally document that the resulting payload design does not materially 
affect the astronaut’s ability to operate and interact with the payload. The HFIT process 
is fully ISO 9000 compliant and works concurrently with NASA’s formal systems 
engineering work flow. Due to its success with payloads, the HFIT process is being 
adapted and extended to ISS systems hardware. Key aspects of this process are also 
being considered for NASA’s Space Shuttle replacement, the Crew Exploration Vehicle. 


Introduction 

NASA’s science payloads account for most of the 
scientific research accomplished on the 
International Space Station (ISS), and their relative 
ease-of-use is critical given limited astronaut crew 
time available to conduct experiments. NASA’s 
formal system engineering process for development 
of these space payloads includes formal rigorous 
tracking of all applicable requirements. The 
verification plan and verification testing are tracked 
individually for each requirement, and any 
requirement violation has to be resolved at a formal 
NASA payload review board. Although this 
process is effective in ensuring that all requirements 
are addressed, it resulted in a relatively large 
number of human factors requirements violations. 


In fact, violations of human factors requirements 
accounted for about two-thirds of all waivers 
(exceptions) brought before the NASA payloads 
control board which formally accepted or rejected 
these exception requests prior to certification for 
space flight. 

In 2002, managers of NASA’s ISS Payloads Office 
began exploring options with NASA human factors 
engineering staff to reduce this high volume of 
human factor requirements exceptions coming 
before the payload control board. They noted an 
on-going, successful verification process for 
labeling, led by NASA human factors engineering. 
The ISS Payload Label Approval Team (IPLAT) 
has been in operation since 1998, and has virtually 
eliminated the need for labeling requirements 



exceptions. The IPLAT process is invoked via a 
single requirement that authorizes the IPLAT team 
to evaluate and formally verify the entire set of 
labeling requirements. 

The Human Factors Implementation Team (HFIT) 
process was developed to cover those human factors 
requirements not directly related to labeling, and 
was based on IPLAT. Early in this process, along 
with participation in design reviews, the HFIT team 
performs a preliminary evaluation of prototype or 
engineering hardware. Because of this early 
involvement, any design revisions needed to better 
accommodate human factors requirements are 
relatively inexpensive and sometimes cost free. 
During this preliminary evaluation, all potential 
requirements violations are formally tracked, and 
the HFIT team provides specific guidance on how 
to address each identified issue. As the design 
matures, HFIT personnel track progress in meeting 
requirements. 

In some cases, it may not be feasible to meet the 
exact criterion of a given requirement. However, as 
long as the hardware developer has followed HFIT 
guidance, HFIT will work with the Astronaut office 
to do an operational evaluation of the science 
payload to assess the ease or difficulty of 
interacting with the payload. If the payload can be 
operated without significant usability problems, 
HFIT has the authority to close verification on such 
requirements without taking it before the NASA 
payload board. 

The HFIT process has been in place since early 
2003, and verification has been closed on more than 
45 science payloads. Because of the greatly 
reduced need to prepare and approve payload 
requirements exceptions at formal NASA board 
proceedings, it is conservatively estimated that 
more that $2.4 million in costs have been avoided. 
This is estimated by multiplying the number of 
avoided exceptions (160) by the average cost of 
preparing, revising, and obtaining approval for a 
given exception ($15,000 - $20,000 each). To 
date, this cost avoidance is conservatively estimated 
at 160 X $15,000 = $2.4 Million. This cost benefit 


is greater than contractor costs for salaries and 
travel. 

Practice Innovation and Cost Benefit 

The innovation in human factors requirements 
integration relates to a process that succeeds in 
bringing three key aspects together. That is, the 
formal authority of HFIT team as the primary 
source for human factors verification that 1) 
performs preliminary evaluations and provides 
design guidance to payload developers during early 
stages of hardware development, 2) can resolve 
technical requirements violations without going 
before a formal NASA payloads board as long as 
there is no significant operational impact, and 3) has 
virtually eliminated human factors requirements 
exceptions at NASA payload boards, thus avoiding 
$2.4 million in cost over 4 years, more than 
compensating for the labor and travel costs of HFIT 
personnel. 

Early involvement of human factors 
Early involvement by human factors professionals 
is often cited as desirable in systems engineering of 
hardware and systems (Chapanis, 1996). This early 
involvement can identify human factors issues 
when multiple solutions can be considered, and 
design changes are not costly to implement, and 
may result in zero cost. Early involvement can be 
especially useful when human factors engineers 
actively suggest design options and design 
solutions, rather than simply enumerating problems 
in initial design. When human factors only provide 
inputs late in the process, identified human factors 
issues may be very expensive to resolve, and 
suboptimal designs may be accepted. 

In terms of innovation in human factors practice, 
the key is the combination of multiple elements: 1) 
early involvement by HFIT, 2) authority HFIT has 
to resolve technical requirements violations on its 
own, and 3) demonstrated cost benefit. 

Technically, using the HFIT process is an option for 
payload developers — they can use the “old” process 
where the payload developer is responsible for 
tracking and verifying each single requirement. 



And if the exact technical metric of a requirement 
can’t be met, the developer is responsible for going 
before a formal NASA control board before their 
payload can be certified for flight. However, the 
HFIT process has a credible track record of saving 
hassle, time and money for payload developers. 
Virtually all payload developers which started 
processing since 2003 have voluntarily chosen the 
HFIT process. Once the HFIT process is chosen, 
the early involvement of HFIT engineers is 
specifically called for — including a preliminary 
evaluation, enumeration of all potential human 
factors requirements issues, and specific 
suggestions for resolving these issues. HFIT also 
participates in design reviews. Because the HFIT 
team has extensive experience with requirements 
verification for multiple payload designs, they are 
able to provide design suggestions that address the 
intent of all requirements, and are feasible, cost 
effective, and practical to implement. 

Another aspect of the HFIT process that enhances 
its credibility with payload developers is the 
“fairness principle.” This effectively means that if 
developers provide access to all pertinent design 
information during the preliminary evaluation, and 
follow the specific suggestions to resolve all 
identified requirements issues, there won’t be any 
surprises during subsequent evaluations (HFIT 
doesn’t change the rules on them). That is, no 
brand new issues will somehow surface later that 
could impact the cost or schedule for the hardware, 
except identification of newly discovered safety 
issues. 

Resolution of technical requirements violations 
In some cases, it may not be technically feasible to 
meet the specific metric of a requirement. For 
example, there are requirements for minimum 
spacing between control switches, but the small, 
fixed size of front panels on some payloads limits 
the space available to provide separation between 
controls. In such cases, HFIT has the authority to 
work with crew astronaut office to evaluate the 
operational usability of the payload interface with 
such technical requirements violation(s). If the 
HFIT team and astronauts office determine there is 
not a significant degradation of operational 


usability, HFIT has the authority to formally resolve 
this issue on its own without the lengthy and costly 
process of presenting an exception before a NASA 
control board. 

Cost benefit 

The cost benefit estimate for the HFIT process is 
based on costs avoided by not having to prepare 
formal exception documentation and presentation(s) 
for NASA payload control board. Based on formal 
records kept for the ISO 9000-compliant HFIT 
process over the four years from 2003 through 
2007, there have been 160 technical requirements 
violations that have been resolved via HFIT 
process, thus avoiding the cost of presenting 
exceptions before a NASA control board. A review 
of historical cost data revealed that approximately 
1.67 - 2.2 person months were required to prepare, 
revise, process, and present the technical details 
necessary to successfully receive NASA control 
board approval for a human requirements exception. 
The effective hourly rate for technical personnel 
that do this work is estimated at $56/hour (in 2005 
dollars), including salary, benefits, contract 
management overhead, etc. 

The average cost for processing a single exception 
is then: 

(1.67 - 2.2 person-months) X (160 work hrs./mo.) 

X ($5 6/hr.) = $15K - $20K per exception 

The total cost benefit over the four year period is 
then: 

($15K-$20K per exception) X 160 exceptions = 

$2.4 - $3.2 million total cost benefit 

This cost benefit is greater than contractor cost for 
salaries and travel. 

It is important to note that this is a conservative 
estimate of the cost benefit from HFIT. First, the 
only source of savings considered is from technical 
requirements violations that are handled by HFIT. 
The early involvement of HFIT likely leads to 
complete resolution of many key requirements 
issues — i.e., a cost-effective design solution is 
found for a given requirement, and HFIT doesn’t 



have to do an operation usability assessment 
because there is no technical requirements 
violation. Second, another source of savings for 
payload developers is that HFIT, not the payload 
developer, performs the actual tracking and 
verification of human factors requirements. Also, 
because payloads are better human factored, NASA 
saves valuable astronaut time on board ISS, leading 
to more time for scientific research. An example of 
astronaut research using Microgravity Science 
Glovebox is shown in Figure 1. 



Figure 1. Astronaut Jeff Williams conducting 
science experiment using Microgravity Science 
Glovebox (MSG). 

NASA space payload context 
When considering how this process innovation may 
relate to other systems engineering processes, it is 
important to understand the NASA context, and 
how it is similar to and different from other 
situations. There are basically two key areas to 
consider — 1) payload will be launched into space 
and used aboard the ISS, and 2) the unique systems 
engineering and administrative context for NASA 
payloads processing. 

First, the hardware items being developed are space 
payloads — they will be used by astronauts in 
microgravity and must withstand increased gravity 
and vibrations during launch. Because of the space 
context, there are also severe limits on weight and 
power usage. It costs approximately $10,000 a 
pound to launch space cargo, and there is limited 
electrical power available to power equipment. 
Another constraint is limited astronaut time 
available to conduct science experiments, and thus 
the consistency of crew interfaces helps to conserve 
valuable astronaut crew time. 


Second, the NASA payload process includes about 
125 human factors requirements (not including 
labeling requirements) that are formally 
documented (NASA, 2006). All of these 
requirements are directly assessable via inspection 
or straight forward measurement. Some 
requirements examples include maximum force 
needed to actuate a control, minimum spacing 
between controls, and the color and reflectivity of 
paint or decals on the front panels of payload 
hardware. Another aspect of these requirements is 
that the criterion measurements are repeatable. 
Different human factors engineers can measure the 
same criterion and get the same answer. No 
complex usability evaluations are necessary to 
verify these requirements. 

In terms of the formal systems engineering 
methods, the NASA system is similar to other 
military and governmental systems. The multi- 
stage process includes familiar milestones such as 
preliminary design review, critical design review, 
etc. The HFIT team is cognizant of these design 
process milestones, and HFIT evaluations are 
coordinated to coincide with design reviews. 

Findings 

The HFIT process at NASA is now in its fifth year 
of successful human factors verification for space 
payloads, and has virtually eliminated human 
factors requirements exceptions being presented at 
the NASA control board. This has resulted in 
conservative cost benefit estimate of $2.4 million 
over four years, or $0.6 million per year. 

Even though the use of HFIT is a voluntary choice 
for payload developers, virtually all developers 
have chosen HFIT to save time and money. This 
has been especially beneficial to some of the 
smaller payload developers who have limited or no 
experience developing NASA payloads, such as 
small university laboratories who want to develop 
science experiments that require micro gravity. 
HFIT helps developers from early design stages 
through final bench reviews when payloads are 
formally certified for a specific space flight to ISS. 



In every case, the HFIT team has been involved at 
early design stages, and has provided specific 
guidance on how to address potential human factors 
requirements issues identified during the 
preliminary evaluation. Later, requirements 
verification has been conducted by inspection and 
measurement of actual flight hardware. 

Finally, it’s important to note that the success of 
HFIT has led to its adoption beyond payloads — the 
HFIT process is now being adapted to apply to all 
new systems hardware being developed for ISS, 
including a new exercise treadmill and new waste 
and hygiene compartment. Key aspects of this 
process are also being considered for NASA’s 
Space Shuttle replacement, the Crew Exploration 
Vehicle. 

Discussion and Lessons Learned 

Even though the successful HFIT process is used 
for unique domain of space payloads, the benefits of 
using this process should be able to be generalized 
to other systems engineering contexts. The 
considerations and limits to generalization are 
discussed below, along with selected lessons 
learned. 

The previous success of NASA’s labeling 
verification process, IPLAT, was a key reason that 
HFIT was even considered, and IPLAT also served 
as a model for the development of HFIT process. 
IPLAT had been developed and successfully 
implemented for the relatively narrow domain of 
labeling requirements. Although somewhat broader 
in scope, HFIT requirements are similarly focused 
on directly assessable requirements that can be 
verified by direct inspection or straightforward 
measurement. The criterion measurements for 
HFIT verification are also highly repeatable. 
Additionally, the face validity of HFIT 
requirements is readily discernable and easy to 
communicate to payload developers. 

The successful track record of IPLAT also led to 
acceptance of voluntary HFIT process by payload 
developers. The successful use of HFIT process has 


led to further credibility of HFIT, and Payload 
Integration Managers (PIMs), who are responsible 
for shepherding payloads through the entire NASA 
systems engineering process, all recognize HFIT at 
the focal point for human factors requirements 
integration. 

The early involvement of HFIT, combined with 
HFIT’s authority to resolve technical requirements 
violations without NASA board approval is perhaps 
the key generalizable finding, and directly 
contributed to the $2.4 million cost benefit. 
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